An Open-Source Cryptographic Coprocessor

Current crypto implementations rely on software running under general-purpose operating systems alongside a horde of untrusted applications, ActiveX controls, web browser plugins, mailers handling messages with embedded active content, and numerous other threats to security, with only the OS’s (often almost nonexistant) security to keep the two apart. This paper presents a general-purpose open-source crypto coprocessor capable of securely performing crypto operations such as key management, certificate creation and handling, and email encryption, decryption, and signing, at a cost one to two orders of magnitude below that of commercial equivalents while providing generally equivalent performance and a higher level of functionality. The paper examines various issues involved in designing the coprocessor, and explores options for hardware acceleration of crypto operations for extended performance above and beyond that offered by the basic coprocessor’s COTS hardware. 1. Problems with Crypto on End-user Systems The majority of current crypto implementations run under general-purpose operating systems with a relatively low level of security, alongside which exist a limited number of smart-card assisted implementations which store a private key in, and perform private-key operations with, a smart card. Complementing these are an even smaller number of implementations which perform further operations in dedicated (and generally very expensive) hardware. The advantage of software-only implementations is that they are inexpensive and easy to deploy. The disadvantage of these implementations is that they provide a very low level of protection for cryptovariables, and that this low level of security is unlikely to change in the future. For example Windows NT provides a function ReadProcessMemory which allows a process to read the memory of (almost) any other process in the system (this was originally intended to allow debuggers to establish breakpoints and maintain instance data for other processes [1]), allowing both passive attacks such as scanning memory for highentropy areas which constitute keys [ 2] and active attacks in which a target processes’ code or data is modified (in combination with VirtualProtectEx, which changes the protection on another processes’ memory pages) to provide supplemental functionality of benefit to a hostile process. By subclassing an application such as the Windows shell, the hostile process can receive notification of any application (a.k.a. “target”) starting up or shutting down, after which it can apply the mechanisms mentioned previously. A very convenient way to do this is to subclass a child window of the system tray window, yielding a system-wide hook for intercepting shell messages [ 3]. Another way to obtain access to other processes’ data is to patch the user-to-kernel-mode jump table in a processes’ Thread Environment Block (TEB), which is shared by all processes in the system rather than being local to each one, so that changing it in one process affects every other running process [4]. Although the use of functions like ReadProcessMemory requires Administrator privileges, most users tend to either run their system as Administrator or give themselves equivalent privileges since it’s extremely difficult to make use of the machine without these privileges. In the unusual case where the user isn’t running with these privileges, it’s possible to use a variety of tricks to bypass any OS security measures which might be present in order to perform the desired operations. For example by installing a Windows message hook it’s possible to capture messages intended for another process and have them dispatched to your own message handler. Windows then loads the hook handler into the address space of the process which owns the thread which the message was intended for, in effect yanking your code across into the address space of the victim [ 5]. Even simpler are mechanisms such as using the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs key, which specifies a list of DLLs which are automatically loaded and called whenever an application uses the USER32 system library (which is automatically used by all GUI applications and many command-line ones). Every DLL specified in this registry key is loaded into the processes’ address space by USER32, which then calls the DLL’s DllMain function to initialise the DLL (and, by extension, trigger whatever other actions the DLL is designed for). A more sophisticated attack involves persuading the system to run your code in ring 0 (the most privileged security level usually reserved for the OS kernel) or, alternatively, convincing the OS to allow you to load a selector which provides access to all physical memory (under Windows NT, selectors 8 and 10 provide this capability). Running user code in ring 0 is possible due to the peculiar way in which the NT kernel loads. The kernel is accessed via the int 2Eh call gate, which initially provides about 200 functions via NTOSKRNL.EXE but is then extended to provide more and more functions as successive parts of the OS are loaded. Instead of merely adding new functions to the existing table, each new portion of the OS which is loaded takes a copy of the existing table, adds its own functions to it, and then replaces the old one with the new one. To add supplemental functionality at the kernel level, all that’s necessary is to do the same thing [6]. Once your code is running at ring 0, an NT system starts looking a lot like a machine running DOS. Although the problems mentioned so far have concentrated on Windows NT, many Unix systems aren’t much better. For example the use of ptrace with the PTRACE_ATTACH option followed by the use of other ptrace capabilities provides similar headaches to those arising from ReadProcessMemory. The reason why these issues are more problematic under NT is that users are practically forced to run with system Administrator privileges in order to perform any useful work on the system, since a standard NT system has no equivalent to Unix’s su functionality and, to complicate things further, frequently assumes that the user always has Administrator privileges (that is, it assumes it’s a single-user system with the user being Administrator). While it’s possible to provide some measure of protection on a Unix system by running crypto code as a daemon in its own memory space, the fact that the Administrator can dynamically load NT services (which can use ReadProcessMemory to interfere with any other running service) means that even implementing the crypto code as an NT service provides no escape. 1.1. The Root of the Problem The reason why problems like those described above persist, and why we’re unlikely to ever see a really secure consumer OS is because it’s not something which most consumers care about. One recent survey of Fortune 1000 security managers showed that although 92% of them were concerned about the security of Java and ActiveX, nearly three quarters allowed them onto their internal networks, and more than half didn’t even bother scanning for them [ 7]. Users are used to programs malfunctioning and computers crashing (every Windows NT user can tell you what the abbreviation BSOD means even though it’s never actually mentioned in the documentation), and see it as normal for software to contain bugs. Since program correctness is difficult and expensive to achieve, and as long as flashiness and features are the major selling point for products, buggy and insecure systems will be the normal state of affairs [ 8]. Unlike other Major Problems like Y2K (which contain their own built-in deadline), security generally isn’t regarded as a pressing issue unless the user has just been successfully attacked or the corporate auditors are about to pay a visit, which means that it’s much easier to defer addressing it to some other time [ 9]. Even in cases where the system designers originally intended to implement a rigorous security system employing a trusted computing base (TCB), the requirement to add features to the system inevitably results in all manner of additions being crammed into the TCB, with the result that it is neither small, nor verified, nor secure. An NSA study [10] lists a number of features which are regarded as “crucial to information security” but which are absent from all mainstream operating systems. Features such as mandatory access controls which are mentioned in the study correspond to Orange Book Blevel security features which can’t be bolted onto an existing design but generally need to be designed in from the start, necessitating a complete overhaul of an existing system in order to provide the required functionality. This is often prohibitively resourceintensive, for example the task of reengineering the Multics kernel (which contained a “mere” 54,000 lines of code) to provide a minimised TCB was estimated to cost $40M (in 1977 dollars) and was never completed [11]. The work involved in performing the same kernel upgrade or redesign from scratch with an operating system containing millions or tens of millions of lines of code would make it beyond prohibitive. At the moment security and ease of use are at opposite ends of the scale, and most users will opt for ease of use over security. JavaScript, ActiveX, and embedded active content may be a security nightmare, but they do make life a lot easier for most users, leading to comments from security analysts like “You want to write up a report with the latest version of Microsoft Word on your insecure computer or on some piece of junk with a secure computer?”[ 12], “Which sells more products: really secure software or really easy-to-use software?”[13], and “It’s possible to make money from a lousy product [...] Corporate cultures are focused on money, not product”[ 14]. In many cases users don’t even have a choice, if they can’t process data from Word, Excel, PowerPoint, and Outlook and view web pages loaded with JavaScript and ActiveX, their business doesn’t run, and some companies go so far as to publish explicit instructions telling users how to disable security measures in order to maximise their web-browsing experience [15]. Going beyond basic OS security, most current security products still don’t effectively address the problems posed by hostile code such as trojan horses (which the Orange Book’s BellLaPadula security model was designed to combat), and the systems the code runs on increase both the power of the code to do harm and the ease of distributing the code to other systems. This presents rather a gloomy outlook for someone wanting to provide secure crypto services to a user of these systems. In order to solve this problem, we adopt a reversed form of the Mohammed-and-the-mountain approach: Instead of trying to move the insecurity away from the crypto through various operating system security measures, we instead move the crypto away from the insecurity. In other words although the user may be running a system crawling with rogue ActiveX controls, macro viruses, trojan horses, and other security nightmares, none of these can come near the crypto. 1.2. Solving the Problem The FIPS 140 standard provides us with a number of guidelines for the development of cryptographic security modules. NIST originally allowed only hardware implementations of cryptographic algorithms (for example the original NIST DES document allowed for hardware implementation only [ 16][17]), however this requirement was relaxed somewhat in the mid1990’s to allow software implementations as well [18][19]. FIPS 140 defines four security levels ranging from level 1 (the cryptographic algorithms are implemented correctly) through to level 4 (the module or device has a high degree of tamper-resistance including an active tamper response mechanism which causes it to zeroise itself when tampering is detected). To date only one general-purpose product family has been certified at level 4 [20]. Since FIPS 140 also allows for software implementations, an attempt has been made to provide an equivalent measure of security for the software platform on which the cryptographic module is to run. This is done by requiring the underlying operating system to be evaluated at progressively higher Orange Book levels for each FIPS 140 level, so that security level 2 would require the software module to be implemented on a C2-rated operating system. Unfortunately this provides something if an impedance mismatch between the actual security of hardware and software implementations, since it implies that products such as a Fortezza card [ 21] or Dallas iButton (a relatively high-security device) [ 22] provide the same level of security as a program running under Windows NT. It’s possible that the OS security levels were set so low out of concern that setting them any higher would make it impossible to implement the higher FIPS 140 levels in software due to a lack of systems evaluated at